1. The Field of the Invention
This invention relates generally to the field of wireless communication software. In particular, embodiments of the present invention relate to systems and methods for efficiently establishing wireless connections.
2. The Relevant Technology
Short range wireless communication schemes are increasingly used as an alternative to wire-based networks to interconnect computers and computer devices. The use of wireless communications provides a number of advantages, including the elimination of complex, expensive, and inconvenient wire-based connection schemes. While a number of wireless communications standards have been developed for such applications, one popular example is known as “Bluetooth.” The Bluetooth standard uses low power radio frequencies to allow communication between various devices such as mobile phones, laptop and desktop computers, printers, modems, PDAs, etc. This technology was originally envisioned for the purpose of replacing cabling and other hard-wired connection schemes used to connect auxiliary devices to a desktop or laptop computer. However, Bluetooth has further evolved into a method of sending both data and voice signals between a wide range of devices. For example, a Bluetooth-enabled PDA can be configured to automatically connect to a Bluetooth-enabled communications line within a building, therefore gaining wireless access to computing resources, such as printers, an Internet portal, etc.
In an effort to ensure compatibility among Bluetooth implementations, a Bluetooth special interest group (SIG) was formed. One of the main objectives of the Bluetooth SIG is to formulate a standardized specification for every element of Bluetooth. The specification dictates numerous software and hardware characteristics so that devices made by different manufacturers will be compatible with one another. The specification dictates all aspects of Bluetooth technology from the software stack necessary to run Bluetooth devices to the actual hardware requirements.
As per this standard, Bluetooth compatible technology is composed of multiple components that together provide for wireless communication capabilities. For example, each Bluetooth-compatible device is configured with a radio that can transmit and receive wireless signals on a particular frequency band. In addition, there are certain structural elements required for connecting the radio to the specific host device. Further, each Bluetooth-compatible device is also configured with particular software to allow the device to properly process and route data or voice signals. This software is typically referred to as the “protocol stack” because it is composed of numerous components that are each configured to perform a particular function. Information is generally passed between the respective layers of the stack either from the bottom of the stack to the top or vice versa, depending on the direction of the communication involved. The protocol stack is further broken up into a “transport protocol group,” a “middleware protocol group” and an “application protocol group.
In general, the transport protocol group includes functional components that are designed to allow Bluetooth devices to locate one another within a Bluetooth network, and to manage the links that allow higher layer protocols and applications to pass data through the transport protocols. The transport protocol group is comprised of a radio, a baseband controller, a link manager, a logical link control and adaptation protocol (L2CAP), and a host controller interface (HCI). The baseband controller defines how devices search for one another and how they connect to one another via a Bluetooth Device Discovery and Connection process. The baseband controller also defines the master and slave roles between devices. The link manager supervises the creation of pairing between devices and the encryption of data. The link manager also supervises power control among devices. For example, the link manager can initiate a low power adjustment between devices to conserve energy. The L2CAP supports the protocol multiplexing that allows multiple protocols to utilize the same air-interface. It also maintains the desired level of service among devices. The HCI allows higher layers of the stack to access the baseband controller and link manager. The HCI is not a required part of the Bluetooth specification and it can be located above or below the L2CAP depending on the configuration of the particular Bluetooth system. The radio, link manager and baseband controller are sometimes grouped together to form what is referred to as a Bluetooth module. The remaining components of the transport layer are typically located on the actual Bluetooth host device.
The middleware protocol group is directed to functionality that facilitates communication between host applications and the Bluetooth module. The protocols can include both third-party protocols and industry standard protocols specified by the Bluetooth SIG. The middleware protocol group specifically includes a RFCOMM, a service discovery protocol (SDP), a set of IrDa object exchange protocols, and a telephony control protocol (TCS). The RFCOMM protocol creates virtual serial ports to facilitate the replacement of cables with a wireless Bluetooth interface. The SDP protocol defines a standard method for Bluetooth devices to discover and learn about the services offered by other Bluetooth devices within the network. The SDP protocol is often utilized by other protocols for the purpose of identifying what services are available over a wireless air interface. The set of IrDa interoperability protocols helps to define the syntax of the data to be exchanged between devices. The TCS protocol is designed to control the exchange of voice communications between devices.
The application protocol group consists of the various applications that utilize Bluetooth communications. The applications may be unaware that data is being transmitted over a Bluetooth air-interface rather than a standard cable, or the application may be specifically designed to interact with Bluetooth devices.
Bluetooth devices form what are known as “piconets” with one another. A piconet is comprised of one Bluetooth device acting as a master and one or numerous other devices acting as slaves. Both the master and the slave device(s) can transmit and receive data from one another. However, the master device defines the data hopping sequence and is usually the device that initiates the communication. Initiation of a communication depends, in part, on the configuration state of a device. For example, an “active state” is a system configuration in which the slave device is always listening for transmissions from the master. In a “parked state” the slave device is only periodically listening to the master. Thus, a parked slave must become active before it can communicate normally with the master. In addition, there is a sniff state and a hold state, both of which are considered active states. The hold state is used as an alternative to the full active state for the purpose of conserving power. A slave device in a sniff mode essentially communicates with the master at regular intervals rather than always listening. A slave device in a hold mode essentially stops listening to the master for a specified period of time.
Whenever a new wireless device is developed to interface with existing Bluetooth devices, a complete protocol stack must be created. The protocol stack allows the device to communicate with other wireless devices over an air interface. A protocol stack for an individual device is tailored to incorporate the particular protocols and applications which it requires for operation. Some of these protocols are only for the wireless communications. For example, a printer must utilize a particular protocol to obtain the data from the foreign device which it is printing. Each of the applications created for the device further include wireless protocol commands pertaining to the establishment of the wireless link between one or more devices. These commands must conform to a specific format in order to ensure compatibility with other devices.
In a Bluetooth wireless networking environment, applications from the Application Group communicate with various peripheral devices that may or may not be connected over a Bluetooth air-interface. For example, an application may communicate with a printer that is directly connected to the host computer within which the application resides; or alternatively, the application may communicate with a modem that is connected over a Bluetooth air-interface. The peripheral devices are used to perform functions that the application cannot perform independently such as printing a document, transferring information over a phone line, etc. If the device used by a particular application is actively connected over a Bluetooth air-interface it is said to be connected to a Bluetooth communication port (corn port), virtual corn port or a virtual serial port. A communication port must therefore be opened whenever an application wishes to communicate with a wireless device that is not already actively communicating with the host computer in which the application resides. When an application initially tries to transmit data to a wireless device, the request is processed by a Bluetooth connection initiator. The initiator typically has no way of knowing which of the devices within the piconet the application wishes to communicate with. This ambiguity typically results in either a long trial and error process or a user information request before the application can efficiently communicate with the proper device. Likewise, when an application makes an initial request to receive data from a wireless device, the request is processed by a Bluetooth connection acceptor which also has no way to know which of the many wireless devices in the piconet the application wishes to receive data from.
Therefore, there is a need for an improved Bluetooth protocol stack that is capable of storing peripheral device information for each application. In addition, the software stack should be capable of establishing a connection with the proper device or application based upon the stored information without requesting user information or interrupting communications. Such a protocol stack should provide a host system with more versatility over Bluetooth architecture and efficiency of Bluetooth communications.